重構是一種有紀律的技術，用於重組現有的程式碼主體，改變其內部結構而不改變其外部行為。其核心是一系列小型的行為保留轉換。每個轉換（稱為「重構」）所做的不多，但這些轉換的順序可以產生重大的重組。由於每個重構都很小，因此出錯的機率較低。每次重構後，系統都會保持完全運作，降低重組期間系統嚴重損壞的機率。

軟體開發專案中常見的爭論，在於花時間改善軟體品質與專注於釋出更有價值的功能之間。通常交付功能的壓力主導了討論，導致許多開發人員抱怨他們沒有時間處理架構和程式碼品質。這場爭論基於一個假設，即提高品質也會增加成本，這是我們常見的經驗。但反直覺的現實是，內部軟體品質消除了減緩開發新功能的冗餘，從而降低了增強軟體的成本。

重構已發展成一種眾所周知且大多數軟體開發團隊至少聲稱定期進行重構的技術。然而，許多團隊並不了解重構可以使用的不同工作流程，因此錯失了有效將重構納入其開發活動的機會。在此簡報中，我探討了各種不同的工作流程。我希望這將鼓勵團隊更深入地將重構整合到其工作中，從而產生設計更佳的程式碼庫，讓新增功能變得更快速、更容易。

現代 Web 開發有許多挑戰，其中安全性既非常重要，又常被低估。雖然威脅分析等技術日益被認為是任何嚴肅開發的必要條件，但也有某些基本做法是每個開發人員都能且應該例行執行的。

我們軟體系統中的可觀察性一直很有價值，在雲端和微服務的時代變得更加重要。然而，我們新增到系統中的可觀察性往往相當低階且技術性，而且似乎太常需要在我們的程式碼庫中散佈冗長且詳細的呼叫，以呼叫各種記錄、儀器和分析架構。本文說明一種模式，可以清除此混亂，並允許我們以乾淨且可測試的方式新增與業務相關的可觀察性。

當我撰寫處理外部服務的程式碼時，我發現將該存取程式碼分隔成個別物件很有價值。在此，我將展示如何將一些凝結的程式碼重構成此分隔的常見模式。

設計技術通常用於讓系統更靈活，但最後卻變得更難使用。其中一個原因是明確性是一種在設計中常被遺忘的屬性。

您可以使用基於元資料的方法來消除繁瑣的資料導向任務的痛苦。

何時為值建立新的使用者定義類型 (或類別) 的指南。

Kent Beck 在 1990 年代後期開發 極端程式設計 時提出了四個簡單設計規則。我這樣表達它們。

程式碼異味是一種表面現象，通常對應於系統中更深層的問題。這個術語最初是由 Kent Beck 在協助我撰寫 重構 一書時提出的。

「命令查詢分離」一詞是由 Bertrand Meyer 在他的著作「物件導向軟體建構」中提出的，這本書是 OO 早期最具影響力的 OO 書籍之一。（第一版是最有影響力的，第二版很好，但您需要在健身房待上幾個月才能舉起它。）

撰寫可維護程式碼時，最強大的工具之一是將大型方法分解成命名良好的小型方法，這是一種 Kent Beck 稱之為組合式方法模式的技術。

每當兩個或三個值聚集在一起時，請將它們變成一個 $%#$%^ 物件。

-- 我（用聲音會更有趣）

這是重構書籍中我最喜歡的 程式碼異味 之一。當您不斷看到相同的幾個資料項目一起傳遞時，您就會發現它。開始和結束是一個資料塊想要成為 範圍 的一個好例子。通常，資料塊是沒有人會想到變成物件的基本值。

設計良好的軟體是否值得花費心力？

（這是你的字典中新增的內容。）

令人厭惡（形容詞）：無法測試的軟體。

在我的職業生涯中，我聽過許多關於函式長度應該多長的論點。這是更重要問題的代理人 - 我們什麼時候應該將程式碼封裝在自己的函式中？其中一些準則基於長度，例如函式不應大於螢幕上顯示的長度。有些則基於重複使用 - 任何使用超過一次的程式碼都應放入自己的函式中，但僅使用一次的程式碼應保留在內聯中。然而，對我來說最有意義的論點是意圖和實作之間的分離。如果你必須花費精力查看程式碼片段才能找出它在做什麼，那麼你應該將它萃取到一個函式中，並將函式命名為那個「什麼」。這樣，當你再次閱讀它時，函式的目的就會立即出現在你面前，而且大部分時間你不需要關心函式如何實現其目的 - 這是函式的內文。

在我看來，四人幫 是有史以來關於物件導向設計寫得最好的書 - 可能涵蓋任何設計風格。這本書對軟體產業影響很大 - 只要看看充滿 GOF 模式的 Java 和 .NET 函式庫就知道了。

自測程式碼是我在 重構 中用來指稱撰寫全面自動化測試與功能性軟體相結合的實務。如果做得好，這將允許您呼叫執行測試的單一指令，而且您有信心這些測試將找出隱藏在程式碼中的任何錯誤。

軟體系統容易累積雜質，也就是內部品質的缺陷，使得修改和進一步擴充系統比理想情況下更加困難。技術債務是一個由 Ward Cunningham 創造的比喻，用來構思如何處理這種雜質，將其視為一種財務債務。新增新功能所需付出的額外努力，就是支付債務的利息。

測試驅動開發 (TDD) 是一種透過撰寫測試來引導軟體開發的軟體建置技術。它是由 Kent Beck 在 1990 年代後期作為極限程式設計的一部分所開發。基本上，我們重複執行三個簡單的步驟

Yagni 最初是一個縮寫，代表「你不需要它」。這是一個來自 極限程式設計 的咒語，經常在敏捷軟體團隊中普遍使用。這是一個聲明，表示我們假設我們的軟體在未來需要某些功能，但現在不應該建置，因為「你不需要它」。